[PATCH 21/24] Remove closing braces in Apple cores names

Gbp-Pq: Topic upstream
Gbp-Pq: Name 0021-Remove-closing-braces-in-Apple-cores-names.patch

[PATCH 20/24] lscpu: (arm) don't use space in names

It's seems better to be consistent and use the same convention for all
the names.

Signed-off-by: Karel Zak <kzak@redhat.com>
Gbp-Pq: Topic upstream
Gbp-Pq: Name 0020-lscpu-arm-don-t-use-space-in-names.patch

[PATCH 19/24] lscpu: add missing Apple parts

Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
Gbp-Pq: Topic upstream
Gbp-Pq: Name 0019-lscpu-add-missing-Apple-parts.patch

[PATCH 18/24] lscpu: make Apple part names human-friendly

The internal Apple model numbers for the SoCs are somewhat
confusing given that they are mostly similar and differ by only
one or two digits. Instead, use the public nomenclature for these
chips to avoid ambiguity and beautify the output.

Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
Gbp-Pq: Topic upstream
Gbp-Pq: Name 0018-lscpu-make-Apple-part-names-human-friendly.patch

[PATCH 17/24] Fix formatting.

Gbp-Pq: Topic upstream
Gbp-Pq: Name 0017-Fix-formatting.patch

[PATCH 16/24] Adding Apple core names, distinguish by SoC/SiP name

Gbp-Pq: Topic upstream
Gbp-Pq: Name 0016-Adding-Apple-core-names-distinguish-by-SoC-SiP-name.patch

[PATCH 15/24] Add Makalu/Makalu-ELP (A715/X3)

Also fix names of A510/A710 cores

Gbp-Pq: Topic upstream
Gbp-Pq: Name 0015-Add-Makalu-Makalu-ELP-A715-X3.patch

[PATCH 14/24] lscpu: Add Snapdragon parts

QC updated the kernel cputype.h to include the Kyro 4xx and 3xx Silver
part numbers's. Lets sync that commit and naming.

Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Gbp-Pq: Topic upstream
Gbp-Pq: Name 0014-lscpu-Add-Snapdragon-parts.patch

[PATCH 13/24] sfdisk: inform about failed fsync() [coverity scan]

Signed-off-by: Karel Zak <kzak@redhat.com>
Gbp-Pq: Topic upstream
Gbp-Pq: Name 0013-sfdisk-inform-about-failed-fsync-coverity-scan.patch

[PATCH 12/24] libfdisk: (gpt) don't ignore fsync() errors

Signed-off-by: Karel Zak <kzak@redhat.com>
Gbp-Pq: Topic upstream
Gbp-Pq: Name 0012-libfdisk-gpt-don-t-ignore-fsync-errors.patch

[PATCH 11/24] sfdisk: improve code readability for coverity scan

Signed-off-by: Karel Zak <kzak@redhat.com>
Gbp-Pq: Topic upstream
Gbp-Pq: Name 0011-sfdisk-improve-code-readability-for-coverity-scan.patch

[PATCH 10/24] libfdisk: make scripts portable between different sector sizes

Fixes: https://github.com/util-linux/util-linux/issues/1744
Signed-off-by: Karel Zak <kzak@redhat.com>
Gbp-Pq: Topic upstream
Gbp-Pq: Name 0010-libfdisk-make-scripts-portable-between-different-sec.patch

[PATCH 09/24] fdisk: make it more obvious that DOS means MBR

Fixes: https://github.com/util-linux/util-linux/issues/1890
Signed-off-by: Karel Zak <kzak@redhat.com>
Gbp-Pq: Topic upstream
Gbp-Pq: Name 0009-fdisk-make-it-more-obvious-that-DOS-means-MBR.patch

[PATCH 08/24] fdisk: fix --output option parsing

Fixes: https://github.com/util-linux/util-linux/issues/1859
Addresses: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022249
Signed-off-by: Karel Zak <kzak@redhat.com>
Gbp-Pq: Topic upstream
Gbp-Pq: Name 0008-fdisk-fix-output-option-parsing.patch

[PATCH 07/24] kill: Support mandating the presence of a userspace signal handler

In production we've had several incidents over the years where a process
has a signal handler registered for SIGHUP or one of the SIGUSR signals
which can be used to signal a request to reload configs, rotate log
files, and the like. While this may seem harmless enough, what we've
seen happen repeatedly is something like the following:

1. A process is using SIGHUP/SIGUSR[12] to request some
   application-handled state change -- reloading configs, rotating a log
   file, etc;
2. This kind of request is deprecated and removed, so the signal handler
   is removed. However, a site where the signal might be sent from is
   missed (often logrotate or a service manager);
3. Because the default disposition of these signals is terminal, sooner
   or later these applications are going to be sent SIGHUP or similar
   and end up unexpectedly killed.

I know for a fact that we're not the only organistion experiencing this:
in general, signal use is pretty tricky to reason about and safely
remove because of the fairly aggressive SIG_DFL behaviour for some
common signals, especially for SIGHUP which has a particularly ambiguous
meaning. Especially in a large, highly interconnected codebase,
reasoning about signal interactions between system configuration and
applications can be highly complex, and it's inevitable that on occasion
a callsite will be missed.

In some cases the right call to avoid this will be to migrate services
towards other forms of IPC for this purpose, but inevitably there will
be some services which must continue using signals, so we need a safe
way to support them.

This patch adds support for the -r/--require-handler flag, which checks
if a userspace handler is present for the signal being sent. If it is
not, the process will be skipped.

With this flag we can enforce that all SIGHUP reload cases and SIGUSR
equivalents use --require-handler. This effectively mitigates the case
we've seen time and time again where SIGHUP is used to rotate log files
or reload configs, but the sending site is mistakenly left present after
the removal of signal handler, resulting in unintended termination of
the process.

Signed-off-by: Chris Down <chris@chrisdown.name>
Gbp-Pq: Topic upstream
Gbp-Pq: Name 0007-kill-Support-mandating-the-presence-of-a-userspace-s.patch

[PATCH 06/24] lib/procfs: add function to parse /proc/#/stat

Signed-off-by: Karel Zak <kzak@redhat.com>
Gbp-Pq: Topic upstream
Gbp-Pq: Name 0006-lib-procfs-add-function-to-parse-proc-stat.patch

[PATCH 05/24] lsblk: fix endless loop if device specified more than once

Fixes: https://github.com/util-linux/util-linux/issues/1814
Signed-off-by: Karel Zak <kzak@redhat.com>
Gbp-Pq: Topic upstream
Gbp-Pq: Name 0005-lsblk-fix-endless-loop-if-device-specified-more-than.patch

[PATCH 04/24] libuuid: check clock value from LIBUUID_CLOCK_FILE

The clock value from the LIBUUID_CLOCK_FILE must be checked in
case of an update of libuuid. If clock==CLOCK_SEQ_CONT it must
be set to a new value.

Signed-off-by: Karel Zak <kzak@redhat.com>
Gbp-Pq: Topic upstream
Gbp-Pq: Name 0004-libuuid-check-clock-value-from-LIBUUID_CLOCK_FILE.patch

[PATCH 03/24] uuidd: fix random UUIDs

Commit f27876f introduces copy & past bug and replaces
__uuid_generate_random() with __uuid_generate_time().

Fixes: https://github.com/util-linux/util-linux/issues/1837
Signed-off-by: Karel Zak <kzak@redhat.com>
Gbp-Pq: Topic upstream
Gbp-Pq: Name 0003-uuidd-fix-random-UUIDs.patch

[PATCH 02/24] libuuid: Implement continuous clock handling for time based UUIDs

In a uuidd setup, the daemon is a singleton and can maintain it's own
resources for time based UUID generation. This requires a dedicated
'clock sequence range' but does not need any further lock/update of
the LIBUUID_CLOCK_FILE from uuidd. The range of available clock values
is extended by a continuous handling of the clock updates - instead of
updating the value to the current timestamp, it is incremented by
the number of requested UUIDs.

Gbp-Pq: Topic upstream
Gbp-Pq: Name 0002-libuuid-Implement-continuous-clock-handling-for-time.patch

[PATCH 01/24] lib/path: ul_path_cpuparse: fix parsing of empty sysfs files

Kernel 5.15 returns empty content for topology/thread_siblings on
aarch64 platform, which in conjunction of uninitialized `buf` memory
buffer results in the garbage:

 (gdb) p buf
 $14 = " @\377\367\177\000\000\000\275\000\347j\032\236"

This garbage is then being later consumed by underlying helper functions
like for example cpumask_parse() and this leads to the following crash
later:

 in __libc_free (p=0x7ff7f67c00) at src/malloc/mallocng/free.c:105
 in free (p=<optimized out>) at src/malloc/free.c:5
 in add_cpuset_to_array (setsize=<optimized out>, set=<optimized out>, items=<optimized out>, ary=<optimized out>) at ../sys-utils/lscpu-topology.c:29
 in cputype_read_topology (cxt=cxt@entry=0x7ff7fffe70, ct=0x4298a0) at ../sys-utils/lscpu-topology.c:153
 in lscpu_read_topology (cxt=cxt@entry=0x7ff7fffe70) at ../sys-utils/lscpu-topology.c:629
 in main (argc=1, argv=0x7ffffffdb8) at ../sys-utils/lscpu.c:1341

It looks like the problem is that current logic expects fgets() to set
errno on failure, but fgets() is not documented to do so and and neither
glibc nor musl set errno.  So if errno was set to 0 before fgets() call,
the failure from fgets() is ignored and then invalid buffer is being
parsed.

Fixes: #1810
Suggested-by: Thomas Weißschuh <thomas@t-8ch.de>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Gbp-Pq: Topic upstream
Gbp-Pq: Name 0001-lib-path-ul_path_cpuparse-fix-parsing-of-empty-sysfs.patch

Use sensible-pager

Closes: #1014368
Gbp-Pq: Topic debian
Gbp-Pq: Name sensible-pager.patch

Install lsfd into /usr/bin

Gbp-Pq: Topic debian
Gbp-Pq: Name lsfd-usrbin.patch

hardlink tests: set known failed

sha256 cannot be initialized on some archs / buildds.

Gbp-Pq: Topic debian
Gbp-Pq: Name hardlink-tests-known-failed.patch

Use non-deprecated chown syntax

Closes: #1007139
Gbp-Pq: Topic debian
Gbp-Pq: Name chown-non-deprecated.patch

verbose-tests

Enable verbose tests and print content of failing tests output file.

Gbp-Pq: Topic debian
Gbp-Pq: Name verbose-tests.patch

util-linux: getopt(1) should point to where examples are on a Debian system

Debian BTS #913049

Gbp-Pq: Topic debian
Gbp-Pq: Name man-getopt-examples.patch

util-linux (2.38.1-4) unstable; urgency=medium

  [ Helmut Grohne ]
  * Build-Depend on libcrypt-dev explicitly (Closes: #1024794)

  [ Chris Hofstaedtler ]
  * script: abort if unused arguments given (Closes: #1016193)

[dgit import unpatched util-linux 2.38.1-4]

Import util-linux_2.38.1-4.debian.tar.xz

[dgit import tarball util-linux 2.38.1-4 util-linux_2.38.1-4.debian.tar.xz]

Import util-linux_2.38.1.orig.tar.xz

[dgit import orig util-linux_2.38.1.orig.tar.xz]